Internet Info 1994 March/Internet Info CD-ROM (Walnut Creek) (March 1994).iso/inet/ietf/npp/npp-minutes-90dec.txt

Text File | 1993-02-17 | 9KB | 251 lines

CURRENT_MEETING_REPORT_



Reported by Glenn Trewitt/DEC

NPP Minutes

Agenda


   o ``Wire Protocol''
   o RFC-1179 -- Line Printer Daemon Protocol
   o Network Printing Working Group Charter
   o Printer Access Protocol Proposal


Two items were added:

   o Palladium
   o ``Son of LPR'' services

``Wire Protocol''

Glenn Trewitt advised the Working Group of the decision of the Telnet
Working Group on the Wire Protocol, as described in the Agenda.

The purpose of the Wire Protocol was to provide a standard mechanism for
establishing a TCP connection to one of many physical ports on a host,
e.g., a line on a terminal server.  This connection should be capable of
being 8-bit transparent.  In Vancouver, the Working Group agreed that
this ``protocol'' should be taken to the Telnet Working Group for
further action.  Bill Westfield agreed to do this.  The result was
somewhat surprising.  The general consensus was that most of the
terminal server vendors already provide a mechanism for doing this
(generally by letting the user connect to a particular TCP port in order
to get to a particular line or rotary with specified characteristics.
The only advantage gained by defining a protocol to select the line and
its characteristics would be to provide a standard
protocol-function->line mapping.  This was not viewed as providing a
significant ``win'' over the existing implementations, which work fine,
once you figure out the right TCP port number.

To quote Bill:  ``You ought to specify that the endpoint needs to be
able to talk to an arbitrary tcp host/port, using the `stream' mode that
most terminal server vendors now supply.''

                                   1






Trewitt feels this is an implementation issue (making lpd have the right
functionality for connecting to printers) rather than a protocol issue
(defining a protocol to do something that is currently not do-able or
not standardized).

RFC-1179 -- Line Printer Daemon Protocol

RFC 1179 has been issued as ``informational'', and there was some
question about the actual purpose of the RFC -- if we are specifying
some changes to the de-facto protocol, it really needs to be in the
standards track.  If the intent is truly informational, it must only
specify things that exist in common implementations.  (This was agreed
to mean ``the BSD lpd server''.)

The major issue that was discussed was the order of data and control
files - existing (big-machine) implementations take the data files first
and send the control file last.  ``Small-machine'' implementations
typically can't spool the data files to wait and see what the control
file says to do with it.  As a result, these implementations must print
the data file as best they can, without the help of any information that
might be contained in the control file.  A secondary (but still
important) issue is that many small systems can't predict in advance,
the size of the files to be printed (other than by storing them first,
which they can't do).

The existing RFC attempts to address these issues by changing the
protocol slightly.  The consensus was that, even though these were
extremely desirable modifications, we couldn't change the protocol and
still issue an informational RFC. There wasn't much support for the
notion of pushing these modifications through the standards process,
because there is so much old, ``free'' BSD code out there that won't get
changed.

It was suggested that anybody who wants to get these issues dealt with
should go to the source, Berkeley, and hand them source code for a
backward-compatible lpd that has these problems fixed, and get it
incorporated into 4.4 BSD.

As far as errors in the RFC, there was discussion about some of the
things that it leaves unsaid.  In particular, the BSD implementation of
lpd is very picky about the order in which various commands are given.
This makes it very difficult to implement a client, even if you have a
complete, correct specification of the commands and their arguments (as
in the RFC).

The following are action items:



                                   2






   o Edit the RFC to remove the upgrades.
   o Add a section that discusses the order dependencies of the
     commands.

Network Printing Working Group Charter

We agreed that the Chair should write a new Charter.  It will
incorporate the goals of the Working Group, as discussed in these
minutes.

Printer Access Protocol Proposal

The reaction to PAP was mostly positive.  The consensus was that it is
adequate for a base.  There was significant discussion on the following
points:

Security

There was significant concern over security, of several varieties:


  1. Authentication of the job, to the printer; to ``keep students from
     printing on the Chancellor's printer''.
  2. Encryption of the job, on its way to the printer.
  3. Mechanisms to support military security, e.g., printers that might
     print secret documents.


Items 1 and 2 received the most interest.  We need to work with the SAAG
on this.

Standardization of Keywords

PAP uses ASCII strings to report on resources and capabilities.  The
possible values and their meanings are not defined in the specification.
For example, the values reported by the ``show'' command are not
documented.  This must be fixed -- implementation isn't possible as the
document stands.

Support for Requesting Facilities.

PAP provides, with the ``show'' command, facilities to report the

                                   3






availability of various resources, such as paper trays, fonts, and page
description languages.  It was pointed out that there was no way to
request that these resources be used.  Trewitt observed that most PDLs
provide these mechanisms.

The apparent concern is to provide a way to set the font, paper size,
etc., for *TEXT* to be printed on a printer.  This seems to be asking
for a ``text'' page description language.  The possibility that was
discussed was to define command(s) and options which would request
resources.  Trewitt feels this is a bad idea, as these requests could
get in the way of the facilities of more advanced PDLs.  He suggests a
more favorable approach would be to formalize the concept of a ``text''
page description language, and define mechanisms within that to request
paper size, etc.

More discussion on the mailing list is definitely required.

Internationalization

An observation was made that it was important that where parameters are
supplied by users, (e.g., everything in the ``soj'' command), it be
possible to use 8-bit character sets so that customers in Sweden (for
example) would be able to have their name appear properly on the banner
page.

Palladium

Digital Equipment (in the person of Richard Hart) has ``set aside''
Palladium for consideration, for the moment.  Palladium's upper layers
are making good progress through Posix.  Palladium's lower layers depend
upon some RPC. Since there isn't currently an Internet-Standard RPC (and
there aren't any signs of one appearing soon), he decided that now was
not the time for standardization in the IETF forum.

Son of LPR

This still leaves us with the question of:  ``What do we do to provide
better user services for printing?''  PAP only provides Spooler->Printer
services.  There is still a need for User->Spooler and Spooler->Spooler
services.  Lpr/lpd fills this niche right now, and Palladium may fill
the void later, but right now we have nothing that anybody particularly
wants.

We discussed the possibility of ``fixing'' lpr/lpd.  There wasn't any
great consensus that it is a worthwhile starting point.  Upon reflection
it did not seem that anyone liked that idea.  So, what we *will* do,

                                   4






before the next IETF meeting, is to come up with a list of services that
we want to see available from this protocol.



                                   5






Attendees

Anne Ambler              [e-mail]
Philip Budne             [e-mail]
George Conant            [e-mail]
Robert Gilligan          [e-mail]
Russell Hobby            [e-mail]
Joshua Littlefield       [e-mail]
John Lunny               [e-mail]
Donald Merritt           [e-mail]
Oscar Newkerk            [e-mail]
Brad Parker              [e-mail]
Michael Reilly           [e-mail]
Bill Rust                [e-mail]
Richard Smith            [e-mail]
Glenn Trewitt            [e-mail]
John Veizades            [e-mail]
Steven Waldbusser        [e-mail]



                                   6